Skip to content

[DEBT] CLAUDE.md out of date: Stage 3 opened in May; "external integrations" non-goal never amended - #238

Open
rafaeldearaujop wants to merge 1 commit into
mainfrom
docs/stage-3-status-adr
Open

[DEBT] CLAUDE.md out of date: Stage 3 opened in May; "external integrations" non-goal never amended#238
rafaeldearaujop wants to merge 1 commit into
mainfrom
docs/stage-3-status-adr

Conversation

@rafaeldearaujop

Copy link
Copy Markdown

[DEBT] CLAUDE.md out of date: Stage 3 opened in May; "external integrations" non-goal never amended

Em uma frase: o arquivo que orienta toda sessão de agente no repo diz
que o Stage 3 é "próximo" e que "integrações externas foram removidas" —
mas o Stage 3 abriu em maio de 2026 com a integração Datadog, de forma
deliberada e documentada; um agente que siga o CLAUDE.md à letra pode
recusar ou desfazer trabalho legítimo.

Aberta como PR direta, não como issue: é correção factual de doc mais um
ADR que registra decisão já tomada — a revisão do dono acontece na própria
PR. Referências arquivo:linha apontam para main @ da16235. Esta mudança
é independente: toca só documentação. Toda preocupação da análise
adversária tem disposição final.


Qual é a dívida?

Duas afirmações em CLAUDE.md estão factualmente desatualizadas:

1. Tabela de stages (CLAUDE.md:33-34):

| 2 | Intelligence Platform (MVP) | **Current** — … |
| 3 | Scale & Enterprise Readiness | Next — SSO, fine-grained RBAC, cross-system correlation (CI, incidents), anonymized benchmarking |

2. Não-objetivo (CLAUDE.md:70):

- billing, webhooks, or external integrations (the original SaaS scaffold had these; they were intentionally removed)

Enquanto isso, o repositório contém uma integração externa completa:
platform/lib/integrations/datadog/{client,sync}.ts,
platform/src/app/api/integrations/datadog/events/route.ts,
platform/src/app/api/cron/sync-integrations/route.ts,
iris/analysis/dora_real.py, docs/integrations/datadog.md,
docs/PLAN-datadog.md, e a seção "DORA (real) — Datadog-derived" em
docs/METRICS.md.

E docs/DECISIONS.md não tem entrada sobre a abertura do Stage 3 — a
entrada de 2026-04-12 diz literalmente que os itens de Stage 3 "remain
explicit non-goals until Stage 3 is formally opened" (:225), e a
formalização nunca aconteceu.

Por que é dívida?

  • CLAUDE.md é o arquivo de contexto carregado em toda sessão de Claude
    Code.
    Um não-objetivo desatualizado é uma instrução ativa para recusar
    Stage 3.
  • É o único dos três arquivos de contexto com essa inconsistência:
    AGENTS.md e WINDSURF.md não repetem a tabela nem o não-objetivo
    (verificado por grep). Nenhum .cursorrules, GEMINI.md ou
    .github/copilot-instructions.md existe na raiz.
  • O custo é de trabalho mal direcionado, não de código: um agente ou
    contribuidor novo pode (a) recusar uma tarefa de integração citando o
    não-objetivo, (b) propor "remover a integração Datadog para voltar ao
    escopo", ou (c) rotular como Stage 3 algo que já é prática corrente.
  • A inconsistência induz conclusões erradas em cascata: uma leitura do repo
    guiada pelo CLAUDE.md classifica o Datadog como "drift não declarado";
    a evidência abaixo mostra que foi sancionado.

Como chegou aqui?

O Stage 3 abriu explicitamente, mas fora do CLAUDE.md e do
DECISIONS.md:

  • CHANGELOG.md v1.0.6 (2026-05-13): "Stage 3 opens: Iris can now consume
    a customer's DORA event stream from Datadog and report real Change Failure
    Rate, MTTR, deploy frequency…"
  • docs/PLAN-datadog.md (ligado à issue [FEAT] Integração Datadog — área de Integrations nos settings da org #15): "This is also the implicit
    opening of Stage 3 ('Scale & Enterprise Readiness') since cross-system
    correlation is explicitly listed there in the project CLAUDE.md. We're not
    adopting any other Stage 3 abstractions (RBAC matrix, SCIM, policy engine)
    here — only the integration capability."

Ou seja: a decisão foi tomada e registrada em CHANGELOG + PLAN + issue, mas
a tabela de stages, a linha do não-objetivo e o registro de decisões nunca
foram emendados. O parêntese do não-objetivo ("the original SaaS scaffold
had these") sugere que a linha sempre visou billing/webhooks, não fontes de
dados analíticos — a redação é que ficou ampla demais.

Plano de migração

  • Tabela de stages — Stage 2: manter Current, acrescentar "refinement
    ongoing". Stage 3: "Opened 2026-05 with cross-system correlation
    (Datadog DORA events — CHANGELOG v1.0.6, docs/PLAN-datadog.md, ADR
    2026-05-13 in docs/DECISIONS.md). Still pending: SSO, fine-grained
    RBAC, anonymized benchmarking."
  • Não-objetivo — separar o que foi removido do que é escopo: "billing and
    webhooks (the original SaaS scaffold had these; they were intentionally
    removed). Analytical data-source integrations (e.g. Datadog DORA events)
    are Stage 3 scope; the Datadog integration ([FEAT] Integração Datadog — área de Integrations nos settings da org #15, docs/PLAN-datadog.md)
    is the precedent for how one lands — issue and plan first, then code."
  • CLAUDE.md:36 → "Work that lands should fit Stage 2 refinement or
    Stage 3's opened integration capability — …". :40 ("Focus Areas
    (Stage 2)") mantido: Stage 2 continua Current; definir foco de
    Stage 3 é política de produto, fora desta mudança (ataque 1).
  • ADR em docs/DECISIONS.md"2026-05-13 — Stage 3 Opens With
    Integration Capability Only"
    , no formato do arquivo (Decision / Context
    / Rationale / Consequences), marcado como registrado retroativamente
    em 2026-09-08
    . Registra a decisão já tomada e shipada; não toma
    decisão nova. Inserido em ordem cronológica, antes da entrada de
    2026-06-11.

Critérios de aceite (antes do merge)

  • Revisão do texto do ADR pelo dono do projeto — é o único artefato
    desta issue que fala em nome do projeto (a redação do CLAUDE.md é
    correção factual).

Deadline / gatilho pra pagar

Antes da próxima sessão de agente que toque em integrações ou Stage 3.
Custo estimado: quinze minutos incluindo a revisão do ADR. Não há gatilho de
release — é doc.


Evidência de validação (isolada: main + só esta mudança)

  • CLAUDE.md e docs/DECISIONS.md não são lidos por nenhum script:
    grep -rn "CLAUDE.md" scripts/ iris/ .github/workflows/ retorna só
    iris/analysis/priming_detector.py:47, que verifica existência do
    arquivo (sinal de "priming"), não conteúdo. Risco de código: zero.
  • Suíte completa: 473 pass / 0 fail (LC_ALL=C; inalterada — nenhum
    teste adicionado, nenhum código tocado).
  • A/B end-to-end (engine base vs engine com esta mudança, mesmo
    repo-alvo, runs em par): metrics.json e report.md byte-idênticos.
    (Se o repo analisado for o próprio Iris após o merge,
    priming.files[CLAUDE.md].size_bytes muda — efeito do arquivo analisado
    ter crescido, não do código.)

Como reproduzir

grep -rn "CLAUDE.md" scripts/ iris/ .github/workflows/   # só priming_detector.py:47
LC_ALL=C pytest tests/ -q                                  # 473 passed

Análise adversária (pós-implementação) — toda linha com disposição final

# Ataque Resposta Disposição
1 Meia atualização é pior que nenhuma. A tabela diz "Stage 3 opened", mas :36 mandava "prepare Stage 3" e :40 só lista foco de Stage 2. Esta mudança corrige os fatos (status, não-objetivo, transição em :36) e deixa a política (o que é foco agora) para quem a define. Decidido: transição mínima. :36 passa a "fit Stage 2 refinement or Stage 3's opened integration capability"; nenhum bloco de foco de Stage 3 é inventado — corrigir fatos é escopo, definir política de produto não é.
2 "Issue and plan first, then code" é norma inventada? É exatamente o que aconteceu com a única integração existente (#15 + PLAN), e o próprio PLAN se descreve como pré-requisito. Decidido: precedente, não norma. Redação final: "the Datadog integration (#15, docs/PLAN-datadog.md) is the precedent for how one lands — issue and plan first, then code". Descreve o que o projeto fez; não legisla.
3 Stage 3 "abriu" mesmo? O PLAN diz "implicit opening". Duas fontes independentes (CHANGELOG v1.0.6 e PLAN) usam "opens/opening"; a redação qualifica: "with cross-system correlation… Still pending: SSO, RBAC, benchmarking". ✅ Mitigado pela qualificação — e o ADR fecha a lacuna do "until formally opened" da entrada de 2026-04-12.
4 Vale uma issue, ou é um PR de doc? O trabalho é PR-sized. Mas a issue registra uma decisão de governança (o ADR) que merece revisão explícita do dono, não só um diff. Decidido: issue. O ADR é o motivo; a revisão dele é o critério de aceite.
5 Um agente escrevendo um ADR em nome do projeto. O ADR não decide nada novo: formaliza uma decisão já tomada (CHANGELOG + PLAN + #15), cita as fontes, e está marcado como retroativo. Critério de aceite: revisão do texto pelo dono antes do merge.

Fora do escopo

Issues relacionadas (verificado contra as 63 issues do repo, abertas e fechadas — sem duplicata)

Referências

  • CLAUDE.md:27-36 (stages), :40-45 (focus), :60-72 (non-goals) — main @ da16235.
  • docs/DECISIONS.md:225 ("until Stage 3 is formally opened"), :229-275 (entradas de 2026-04-12, formato de referência), :277 (entrada de 2026-06-11, ponto de inserção).
  • CHANGELOG.md — entradas v1.0.6 "Datadog DORA integration" (2026-05-13) e v1.0.7 "Datadog integration: post-launch fixes".
  • docs/PLAN-datadog.md (cabeçalho e §1); issue [FEAT] Integração Datadog — área de Integrations nos settings da org #15.
  • iris/analysis/priming_detector.py:3,10,47 (único consumidor de CLAUDE.md).

CLAUDE.md still listed Stage 3 as 'Next' and 'external integrations' as removed, four months after v1.0.6 opened Stage 3 with the Datadog DORA integration (#15, docs/PLAN-datadog.md). Update the stage table, narrow the non-goal to billing/webhooks with the Datadog precedent named, adjust the transition line, and add a retroactive ADR (dated 2026-05-13, recorded 2026-09-08) formalizing what CHANGELOG and PLAN already state.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
@vercel

vercel Bot commented Sep 8, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
clickbus-iris Ready Ready Preview Sep 8, 2026 11:41pm UTC

Request Review

@rafaeldearaujop rafaeldearaujop added the type: tech-debt Código sub-ótimo conhecido, workaround, ou cleanup pendente label Sep 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

type: tech-debt Código sub-ótimo conhecido, workaround, ou cleanup pendente

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant